Understanding Web Applications
It
is common in many Web server usage scenarios for a single site to
provide access to different types of content. Web applications are
created within Web sites to point to the physical location of a set of
content files. For example, an online news site might include two
different Web applications: one for registered users and one for
nonregistered users. Each Web application can point to a separate
physical folder on the computer so IIS can determine how to process the
requests. Web applications can also use other methods to ensure that
the same content (such as news stories) is available to both sites.
Creating Web Applications
You
can create new Web applications easily by using IIS Manager.
Right-click the Web site within which you want to create a Web
application and then select Add Application. Figure 11
shows the available options. The first setting option is the alias that
will be used for the site. This is the name that users will type as
part of their URL to connect to the content. For example, if a new Web
application with the alias Engineering is created within the default
Web site, visitors will use a URL such as http://server1.contoso.com/Engineering to access the content. You will learn about application pool setting later in this lesson.
The
Physical Path option enables you to specify the folder in which the
content for the Web application will be stored. Generally, the file
system location should be unique and unshared with other Web
applications. As with the process of creating a site, you will be able
to keep the default setting of Pass-Through Authentication or click the
Connect As button to specify a username and password to use. The Test
Settings button enables you to verify the connection details that you
have entered (if any). The Test Connection dialog box as shown in Figure 12
details that if you keep the default setting, IIS Manager will be
unable to verify the authorization permissions. This is because the specific user context is not defined until a user attempts to access the content.
To
finish the creation of the Web application, click OK. You will now see
a new Web application under the site object in IIS Manager. You can now
also modify other settings for the Web application by using the
Features View.
Managing Web Application Settings
By
default, many of the settings for a new Web application will be
inherited automatically from the Web site in which it was created. This
enables you to use the same default settings easily for each new site.
In most cases, you can also override the settings at the Web
application level based on specific needs of the application. To do
this, double-click any of the items in the Features view and make the
corresponding changes at the Web application level. Most of these
settings will override those that are assigned for the parent site.
Working with Application Pools
One
of the primary concerns with managing Web servers is the potential for
one Web site or application to affect operations of others on the same
computer negatively. Issues such as memory leaks or application bugs
potentially can cause a loss of service or reduced performance for many
different Web applications. Application pools are designed to isolate
different sites from each other so that failures and other problems can
be contained. Within each application pool, worker processes are
actually responsible for completing Web requests. Each application pool
contains its own set of worker processes, so it is impossible for
problems in one pool to affect processes in another. Application pools
can also be started and stopped independently.
By
default, IIS includes the Classic .NET AppPool and DefaultAppPool
application pools along with an application pool that has the same name
as the application itself. Classic .NET AppPool is used to support
applications that require Microsoft .NET Framework 2.0, using classic
Managed Pipeline Mode (a mode that enables .NET code to use methods of
intercepting and responding to requests that are being processed by
IIS). DefaultAppPool, as its name implies, is used to support the
Default Web Site. It also supports Microsoft .NET Framework 2.0, but it
uses the new Integrated Managed Pipeline Mode. You will learn more
about pipeline modes later in this lesson.
By
default, IIS Manager will create a new application pool when you create
a new Web site. The application pool will have the same name as the
site. This is the recommended approach because it allows the processes
within each Web site to run independently of others. When you create a
new Web application, you will have the option of selecting from any of
the available application pools.
Creating Application Pools
IIS Manager includes an Application Pools
object that enables you to manage application pools on the Web server.
The default display will show all the application pools that currently
exist on the server, along with their current status and settings. (See
Figure 13.)
To create a new application pool, right-click the Application Pools object and select Add Application Pool. Figure 14
shows the available options. The name option will be used by systems
administrators to identify the purpose of the application pool. If you
are creating this object to support a specific Web site, include
identifying information in the name. The .NET Framework version options
will be based on which versions are available on the local computer. By
default, the .NET Framework 2.0 and No Managed Code options are
offered. The latter option specifies that .NET functionality will not
be available for Web applications that are part of the pool.
Managed
Pipeline Mode specifies the method that will be supported for code that
needs to intercept and modify Web request processing. The Classic
option supports ASP.NET applications that were written for previous
versions of IIS and that depend on integrating with request pipeline
events. The Integrated mode provides better performance and
functionality for ASP.NET applications and is recommended for those Web
applications that do not depend directly on the Classic Managed
Pipeline Mode. Finally, you can choose whether you want to start the
application pool immediately.
Managing Application Pools
Each
application pool present on a Web server can be started and stopped
independently. Stopping an application pool will prevent requests from
being processed by any applications that are a part of that pool. Users
that attempt to access content from these sites will receive an error
message stating HTTP Error 503, “Service Unavailable.” It is a good
idea to verify which applications are using an application pool before
you stop it. You can do this by right-clicking one of the application
pool items in IIS Manager and selecting View Applications.
Configuring Recycling Settings
An alternative to stopping an application pool is to recycle it using the Recycle
command in the Actions pane. This command instructs IIS to retire any
current worker process automatically after it has executed existing
requests. The benefit is that users will not see a disruption to
service on their computer, but the worker process will be replaced by a
new one as quickly as possible. Recycling application pools is
generally done when issues such as memory leaks or resource usage tend
to increase significantly over time. Often, the root cause of this
problem is a defect or other problem in the application code. The ideal
solution is to correct the underlying application problem. However, it
is possible at least to address the symptoms by using the Recycle command.
In
some cases, you might automatically recycle worker processes based on
resource usage or at specific times. You can access these options by
clicking the Recycling command under Edit Application Pool in the
Actions pane. (See Figure 15.)
The
primary options for recycling settings are either Fixed Intervals
(which are based on specific times or after a fixed number of requests
is processed), or Memory Based Maximums. The most appropriate options
will be based on the specific problems you are trying to troubleshoot
or avoid. In general, recycling application pools too quickly can
reduce performance. However, if a Web application has serious problems,
it is preferable to address them through recycling worker processes
before users see slowdowns or errors on the Web site.
Keeping
track of application pool recycle events is also an important part of
ensuring that your Web server and its applications are running as
expected. For example, if you set the maximum memory settings, you will
likely want to know how often the application pool has been recycled. Figure 16
shows the Recycling Events To Log step that enables you to define which
events are recorded. To view the Recycling Events To Log page, click
Next.
Configuring Advanced Application Pool Settings
In
addition to the basic configuration settings and recycling options for
an application pool, systems administrators can configure additional
details to control the behavior of worker processes. To access these
settings, select an application pool in IIS Manager and click the
Advanced Settings link in the Actions pane. (See Figure 17)
The
options allow for setting detailed parameters related to CPU and memory
resource usage. In general, you should not change these parameters
manually unless you are reasonably sure of their intended effects. Some
modifications can result in reducing processing speed for the
applications that are part of the pool. Others can result in reserving
or using too many system resources for a particular pool.
